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DECLARATION UNDER 37 C.F.R. 8 1.131 



U.S. Patent and Trademark Office 
Commissioner for Patents 



Sir: 



I, Senthil Sengodan, hereby declare, unless otherwise excepted, that: 

1 ) I am named as the sole inventor of the above-identified patent application; 



2) 

3) 
4) 



5) 



6) 



I am presently employed by Nokia Corporation (Nokia), and was employed by 
Nokia during conception and development of the above-identified application. 
Nokia is the assignee of the above-identified application. 

Prior to October 26, 2001, ("the critical date") the actual filing date of U.S. Publ. 
No. US 2003/0081578 Al, I conceived of the invention recited in the pending 
claims of the above-identified application. 

Conception is evidenced by the disclosure document entitled "A Method and 
Apparatus for Address Allocation in GPRS Networks that facilitates end-to-end- 
security" ("GPRS1") prepared by Senthil Sengodan (dates redacted), a copy which 
is attached as Exhibit A. This document was prepared prior to the critical date. The 
date(s) redacted from Exhibit A is/are prior to the critical date. 
The GPRS1 document specifically evidences conception at least of independent 
claims 1, 8, 20, 28, 31, 32 and 39 at least at pages 4-10, among other places. 
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7) The GPRS1 document was subsequently forwarded to my patent attorney, Mr. 
Bradley C. Wright of the law firm Banner & Witcoff, Ltd, for preparation of an 
application. 

8) On October 18, 2001, my employer forwarded my comments and revisions to a draft 
application to Mr. Joseph P. Curtin (also an attorney with Banner & Witcoff, Ltd.). 
The letter communicating the comments and revisions is attached as Exhibit B. 

9) On October 31, 2001, another draft of the patent application was forwarded to my 
employer for review. The e-mail forwarding the additional draft is attached as 
Exhibit C. 

10) On November 26, 2001, my employer forwarded additional information that I 
provided on November 21, 2001, to Mr. Wright and Mr. Curtin. The e-mail string 
communicating the additional information is attached as Exhibit D. 

1 1) In response to the comments sent November 26, 2001, Mr. Wright forwarded a fourth 
draft of the application from Mr. Curtin to my employer for review. We subsequently 
approved the draft and faxed a signed Declaration and a signed Assignment for filing 
on December 18, 2001. The fax forwarding the signed documents is attached as 
Exhibit E. 

12) On December 18, 2001, the above-captioned patent application was filed in the U.S. 
Patent and Trademark Office. 

13) The invention disclosure (Exhibit A) evidences conception, and the preparation and 
revisions to draft patent applications from a time prior to the Critical Date through the 
filing of the Application demonstrate diligence from before the Critical Date until the 



Declaration Under 37 C.F.R. § 1.131 
Appended to Amendment 
Reply to Office Action of September 2 1 , 2005 
Page 3 of 3 



filing of the above-captioned patent application and the constructive 




ion to 



practice of our invention. 

14) All acts referred to in this Declaration were perfoimed either in the United States, or 
in a WTO member country. 

15) The attached Exhibits have not been altered since they were originally submitted to 



the exhibits was contemporaneously written upon receipt of the exhibit in (question; 
and 

16) I declare under penalty of perjury under the law of the United States of America that 
statements made herein of our own knowledge are true and that all statements made 
on information and belief are believed to be true; and further that these statements 
were made with the knowledge that willful false statements and the like so made are 
punishable by fine or imprisonment, or both, under Section 1001 of Title 18 of the 
United States Code and that such willful false statements may jeopardize the validity 
of the application or any patent issuing thereon. 

Respectfully submitted, 



the Patent Committee or otherwise prepared or communicated and any marginalia on 




Senthil Sengodan 



Date 



NOKIA 

INVENTION REPORT 



CONFIDENTIAL 



Title of invention: " — 
A Method and Apparatus for Address Allocation in GPRS 
Networks that facilitates end-to-end security 



THE DESCRIPTION OF THE INVENTION 
MUST BE ATTACHED 




Inventor's name, employee number, title and 

nationality: *) 

Senthil Sengodan 

Assistant Research Manager 

India 



Home Address: *) 

6 Westgate Dr. #205 
Woburn, MA 01803 



Business Unit and cost 
centre: 



Line Managers): Raj Bansai 



Project : *) 



Office address: *) 5 Wayside Road, Burlington, MA 01803, USA 



Project Manager 



Phone: *) +1-781-993-3789 



Fax: *) +1-781-993-1907 



The invention becomes public on: 



/ am/ We are the sole/ and original inventorfs) of this invention. 

The company may, by virtue of applicable legislation, be entitled to full or partial rights to the invention. 

1/ We acknowledge my/ our obligation to sign as inventors) all documents that may be required for protecting the 

invention in different countries. 

^^icaUe to inventions made by inventors employed in Fl, DK, DE and SE only. 




§edfour(4) 1 

tef the Invention Report be responded to wftliih four (4) months: 



Date: 

Signature(s) of Inventor(s): 



*) See the Instructions 
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INSTRUCTIONS FOR COMPLETING THE INVENTION REPORT 

This Invention Report form is used in cases where an invention has been made by an 
employee of the Company. This Invention Report is confidential. Only the Patent 
Department may make copies of signed Invention Reports in order to request opinions or 
reply to the inventor(s). 

The inventor completes the Invention Report and the description of the invention. The 
inventor does not fill in the Invention Report received' field. This field is filled in by the 
Patent Department. The Invention Report must have the names of all the inventors and 
their home addresses, if there is not enough space for all the names, addresses etc, 
please write them on a separate attachment. The first mentioned inventor is assumed to 
be the contact person in matters concerning the Invention Report. In the fields of office 
address, phone and fax, please fill in the contact person's information. Fill in the project 
field, if the invention is made in a project. The original Invention Report is signed by all 
inventors. Each page of the original Invention Report is signed by a Manager. In case it 
is difficult to obtain Manager's signature your Patent Department will take care of it. 

It is suggested that the Invention Report and the description of the invention should be 
filled in as thoroughly as possible. If drawings or other kind of information cannot be 
attached to this form, they should be delivered separately. 

The signed Invention Report is given directly to the local or business unit's Patent 
Department. Invention Report should also be sent by E-mail to the Patent Department. 
The Patent Engineer will inform the inventor of receiving the Invention Report. The 
Patent Engineer will obtain any expert opinions needed to properly evaluate the 
invention, will procure the Compan/s decision and inform the inventor accordingly. 
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DESCRIPTION OF THE INVENTION 

Please, describe your invention in the following order. You can enclose the drawings on a separate 
document. 



1. Field and background of the invention 

NAT and RSIP 

IPv4 is the version of IP (Internet Protocol) that is deployed in toda/s networks - both enterprise networks 
as well as the public Internet. One of the limitations of IPv4 is its limited address space. In order to 
conserve addresses, enterprises and other administrative domains have resorted to the use of private 
addresses. Private addresses are those where the IP address falls In the range: [10.0.0.0 - 
10.255.255.255], or [172.16.0.0. - 172.31.255.255], or [192.168.0.0. - 192.168.255.255]. Private 
addresses that are assigned by an administrative entity within an administrative domain (AD) have 
relevance only within the AD, and such addresses must not be visible outside the AD. The advantage of 
this approach is that different ADs may assign the same private IP address to hosts within their respective 
ADs, without any concern of conflict. When a host that is assigned a private address wishes to 
communicate with a host that is outside its AD, the use of a Network Address Translator (NAT) is 
warranted. A NAT transforms the private IP address (and possibly certain other fields) to a public IP 
address, prior to sending the IP datagram outside its domain. 

This approach of using private addresses within ADs, and the use of NATs at the edges of the ADs, has 
been widely adopted and deployed within enterprises. However, there are two major drawbacks that such 
an approach faces: 

1 . Such an approach breaks the end-to-end security model, and 

2. Certain applications cannot work in the presence of a NAT, unless remedial measures - such as 
the inclusion of an application gateway (proxy) - are taken. 

Figure 1 illustrates a typical scenario involving NATs. 
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B.1 
B.2 



B.4 



Hosts unaware of existence of NAT 



Private Addresses: 



X-»NAT: A.1.B.4; NAT-»Y: B.1.B.4 
Y-»NAT: B.4.B.1; NAT-^X: B.4A1 



10.0.0.0-10.255.255.255 
172.16.0.0-172.31.255.255 
192.168.0.0- 192.168.255.255 



Figure 1: Illustrating NATs 



In order to overcome the disadvantages that face NATs, a mechanism termed Realm Specific IP (RSIP). 
RSIP has been proposed within the IETF and has gained significant support. In RSIP, a host (RSIP client) 
that needs to be assigned an IP address indicates to the server (RSIP server) that is responsible for 
assigning IP address, whether the IP address is needed to communicate with hosts within the AD or 
outside the AD. Based on this information, the RSIP server assigns either a private IP address or a public 
IP address to the host. It is seen that when a private IP address is assigned to a host, the IP datagram 
does not leave the AD. When an IP datagram does leave an AD, the address that is assigned to the 
transmitting host is a public IP address. Thus, the RSIP protocol makes the use of NATs unnecessary, 
thereby avoiding the drawbacks involving NATs. Figure 2 illustrates the usage of RSIP. 

To summarize the discussion thus far, there are generally two broad approaches taken regarding the 
assignment of IP addresses to hosts within an AD: 

1. Assign private addresses to hosts, and when the host needs to communicate with another host 
that is outside the private domain, make use of Network Address Translators (NATs). 

2. Determine whether the host needs to communicate with another host within the same AD or 
outside the AD, prior to assigning an IP address to it. Assign a private address to a host when it 
communicates with another host within the same AD. Otherwise, assign a public address to the 
host. The protocol between the host and the address assigning server is the RSIP protocol. 
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Figure 2: Illustrating RSIP 



IP Addr?s$ Assignment in GPRS Networks 

In the case of GPRS networks, a Mobile Station (MS) is assigned an IP address by the General GPRS 
Support Node (GGSN). Today, such an IP address is an IPv4 address. The protocol that is used for 
address assignment is specific to GPRS networks, and is termed PDP Context Activation. PDP (Packet 
Data Protocol) is a term that is used within GPRS networks to refer to IP addresses, X.25 addresses etc. 
Since we are concerned about IPv4 addresses, the term PDP is synonymous with IPv4 address for this 
discussion. Figure 3 shows a generic GPRS protocol stack, where the IP address on the MS may be 
seen. Figure 4 illustrates the PDP context activation procedure within GPRS networks. An Administrative 
Domain (AD) within GPRS networks (and cellular networks in general) is termed a PLMN (Public Land 
Mobile Network). 



/ have read and understood the invention described in this Invention Report 
Date: 

Signature of Manager 



NOKIA 



Applies, 
X.2S| IP 



SNDCP 



LLC 



R LC _ 
MAC 



GSM RF* 



MS 



CONFIDENTIAL 





RLC 


BSSGP 


MAC 


Netwk 


Serv. 


GSM RF 


Llbis 



BSS 







SNDCP 


GTP 








LLC 


UDP/TCP 






BSSGP 


IP 




Netwk 


L2 




Serv. 




Llbis 


LI 





SGSN 



IP X.25 



GTP 



UDP/TCI 



IP 



L2 



LI 



GGSN 



Figure 3: GPRS Protocol Stack 



Activate PDP Context Request (NSAPI, PDP Type, POP 
Addr, APN, QoS Req, PDP Config Options) 



Create PDP Context Request (PDP Type, PDP Addr, APN, 
QoS Negotiated, TIP, Selection Mode, PDP Config Options) 




Create PDP Context Response (TID. PDP Addr, BB Protocol, 
Reordering Reqd, QoS Negot., PDP Config Options, Cause) 



_ Activate PDP Context Accept (NSAPI, PDP Type, PDP 
[^fn , Addr, QoS Req, Radio Priority Level, PDP Config Options) 





Figure 4: PDP Context Activation 
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2. A summary of the invention 

When IPv4 addresses are assigned to MSs in a GPRS network, one needs to be concerned about 
conserving such addresses, while maintaining end-to-end security and application friendliness at the same 
time. In order to achieve this, this we propose two methods: 

1. Use of the RSIP protocol within GPRS networks. We describe the GPRS functional entities where 
the RSIP client and the RSIP server need to be implemented. 

2. Use of the existing GPRS address assignment mechanism (i.e., PDP context activation procedure) 
with minor modifications, so that a functionality similar to RSIP is achieved. Specifically, we 
propose the use of the Access Point Name (APN) field within the Activate PDP Context Request 
message to convey to the GGSN, whether a private or public IP address needs to be assigned to 
the MS. 



3. Describe the problem which the invention overcomes 

The problem that the invention solves is: 

• To date, we know of no clear mechanism/procedure for IPv4 address assignment to a MS by a 
GGSN within GPRS networks, which has the benefits of conserving IPv4 addresses while at the 
same time maintaing end-to-end security and being application friendly. 



4. How was the problem solved earlier? 

The GPRS standard itself does not specify whether private or public IP addresses are assigned to MSs, 
since that is not a standardization issue. It is not a standardization issue when one relies on the fafct that 
NATs will be used at the PLMN boundaries, in the presence of private IP addresses. In other words, I 
believe that current GPRS deployments rely on the use of NATs at the GGSN when private addresses are 
assigned to the MSs. While this solves the problem of conserving IPv4 addresses, as we saw earlier, it 
does not provide end-to-end security or application friendliness. 



5. How does the invention improve earlier solutions? Advantages and disadvantages of 
the invention? 

I believe that current GPRS implementations using IPv4 addresses rely on the use of NATs when private 
addresses are assigned to the MS. The disadvantages of the use of NATs with regard to end-to-end 
security and application friendliness is known. Consequently, the current solutions suffer from this 
drawback. The proposed solution(s) avoid this drawback since they are based on the priniciple of RSIP. 



6. Brief description of the drawings (Please enclose drawings and figures of the invention 
on a separate document) 

Drawinos Relevant to Proposal 1 

Figure 5 shows the location of the RSIP client and RSIP server functionalities within the GPRS functional 
elements, so that the RSIP protocol may be used for IPv4 address assignment. As seen in the figure, 
RSIP client functionality is needed at SGSNs and GGSNs, but is not needed either at the MS or at BGs. 
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Similarly, RSIP server functionality is needed at GGSNs and BGs, but is not needed either at the MS or at 
SGSNs. 




Figure 5: RSIP Client and Server Locations 



7. A more detailed description of the invention (if known at the moment) 

Detailed Description of Proposal 1 

As seen in Figure 4, during PDP context activation (which is the procedure for IPv4 address assignment 
for the MS), one of the fields in the Activate PDP Context Request message sent from the MS to the 
SGSN is the Access Point Name (APN) field. The APN field is used by the MS to indicate a preference of 
access points or networks for data transfer. The SGSN uses the APN field to choose a suitable GGSN to 
send the Create PDP Context Request message. The Creafe PDP Context Request message sent from 
the SGSN to the GGSN transparently contains the APN field that was used within the Activate PDP 
Context Request message sent from the MS to the SGSN. 

This is illustrated in Figure 5, which shows three GGSNs connected to the Core Network associated with 
an SGSN. Depending on the value of the APN field in the Activate PDP Context Request message sent 
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from the MS to the SGSN, the SGSN chooses a suitable GGSN (one of GGSN 1f GGSN 2 or GGSN 3 ). The 
Create PDP Context Request message is then sent from the SGSN to the chosen GGSN. 

Proposal 1 in this document is that the MS indicates its preference of a private or a public address known 
to the GGSN via the APN field. The GGSN uses this APN field to assign either a private address or a 
public address to the MS. 




Figure 6: Illustrating the use of APN to choose GGSNs 



Detailed Decriotion of Proposal 2 

Several scenarios can be discussed to reason out the placement of the RSIP client and server 
functionalities as shown in Figure 5. Some of these are now discussed. 



Scenarios without mobility 

Consider the case of the outer IP header between an SGSN and GGSN of the same PLMN, for instance, 
that in PLMN A of Figure 5. In this case, private addresses can be used always, and hence, for this 
scenario, we do not need RSIP client or server functionality within any GPRS element. 

Consider the case of the outer IP header between an SGSN and GGSN, where the SGSN and GGSN 
belong to different PLMNs. For instance, consider the case in Figure 5, where the SGSN belongs to PLMN 
A while the GGSN belongs to PLMN B. In this case, two pairs of RSIP client server functionality come into 
play: (1) RSIP client at SGSN A and RSIP server at BG A, and (2) RSIP client at GGSN B and RSIP 
server at BG B. 
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For the case of the inner IP header, the RSIP client is at the SGSN while the RSIP server is at the GGSN. 
This is irrespective of the case whether the GGSN and the SGSN are within the same PLMN or in different 
PLMNs. 



Scenarios with mobility 

Consider the case where a MS that is associated with SGSN B moves to a different location that is 
associated with SGSN A. Let the GGSN be GGSN B, and let us discuss the outer IP header In this case, 
two pairs of RSIP client-server functionality come into play: (1) RSIP client at SGSN A and RSIP server at 
BG A, and (2) RSIP client at GGSN B and RSIP server at BG B. This is identical to the case without 
mobility since the outer IP header is being discussed. 

For this same scenario, let us now discuss the inner IP header. In this case, three pairs of RSIP 
client/server functionalities come into play: (1) RSIP client at SGSN B and RSIP server at GGSN B (2) 
RSIP client at GGSN B and RSIP server at BG B, and (3) RSIP client at SGSN A and RSIP server at 
GGSN A. 

Hence, we see that for all the scenarios discussed, the presence of RSIP client and server functionalities 
as illustrated in Figure 5 serves the purpose. 



8. Explain, how the invention is/can be implemented. Which would be the best mode of 
implementation? 



9. Explain how we can recognise if a competitor is using the same product/feature? 



10.1s it planned to use the invention in a Nokia product? if so, when and in which product? 
Is the invention standard related? 



11. Abbreviations 

AD Administrative Domain 

BG Border Gateway 

GPRS General Purpose Radio System 

IP Internet Protocol 

NAT Network Address Translator 

PDP Packet Data Protocol 

PLMN Public Land Mobile Network 

RSIP Realm Specific IP 

SGSN Serving GPRS Support Node 

12. Any further comments 
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A list of references is as follows: 
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Intellectual Property Rights Dept. 
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Best Regards, 
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To: 



From: 



Patent- Agency Banner- Witcoff (EXT-RES/Washington) 
DeMello Wayne (Nokia-IPR/Boston) 



Cc: 



Subject- 
Sent- 



NC17391 (B&W 5288.00014) 
10/31/01 7:12 PM 



Importance: 



Normal 



Mr. DeMello: 



Due to an oversight on our part, we believed that we had sent you a third draft of the above application on October 19, 
2001. We apologize for the inconvenience and attach a copy of the third draft application and figures for the inventors 
review. 

Many thanks, 

Pam Pease 

Assistant to Brad Wright 
Banner & Witcoff, Ltd. 



DlMAN WDC 410538 3.DOcDlMAN WDC 424848 1.PDF 
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From: 
To: 
Date: 
Subject: 



Pamela Beth Pease 
Curtin, Joseph 
11/26/01 3:08PM 

Email from nokia re: 5288.00014 NC17391 



Hi Joe: 



We just received the below email from nokia. The document can also be found in imanage under the 
client/matter no. Please print this out and place it in the file. 

Thanks 



From: DeMello Wayne (Nokia-IPR/Boston) 

To: Patent-Agency Banner-Witcoff (EXT-RES/Washington) 



Subject: FW: NC17391 additional material 
Sent 11/26/01 6:08 PM 
Importance: Normal 
Brad, 

Here is additional material from the inventor. Please let me know when to expect the next draft. 
BR, 

Wayne 

— Original Message — 

From: Sengodan Senthil (NRC/Boston) 

Sent: Wednesday, November 21, 2001 5:48 PM 

To: DeMello Wayne (Nokia-IPR/Boston) 

Subject: NC17391 additional material 

Hello Wayne, 
GPRSAddr-mod.doc 

I promised to provide Joe Curtin some additional material on NC17391. IVe included the original paper 
that I had forwarded with some additional material included within that. Specifically, two illustrations have 
been added for Proposal 1 under Section 4. These illustrate the functioning of one of the approaches 
proposed In the invention, and the reasoning behind the placement of the RSIP client and server 
functionality at certain network entities (like SGSN, GGSN and BG). Please pass it on to Joe. Thanks & 
hope you have a good thanksgiving holiday! 



- Senthil 



CC: 



Wright, Bradley 
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Re: NC 17391 Declaration and Assign 
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• Comments: 

Hi Joe, 

Faxing over the signed Declaration and Assignment tor NC 17381. plaaaa file this today. 

Thank you, 
Pat 



fMf \aa Griffin 

Patent Assistant to Nokia House Boston 
5 Wayside Road 

Burlington, Massachusetts 01821 
781-993-3822 Office 
781-993-1981 Fax 
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